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- Extensions of time may be available under the provisions of 37 CFR 1.136(a). In no event, however, may a reply be timely filed 
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DETAILED ACTION 



Claims 1-15 have been presented for examination. 
Claims 1-15 have been rejected. 



Priority 

The Examiner acknowledges Applicants' claim for priority to US Provisional Application 
60/258,999 filed on December 29, 2000. 



Specification 

1 . The use of several trademarks, including at least Simula® and Eiffel™, has been noted in 
this application. They should be capitalized wherever they appear and be accompanied by the 
generic terminology. 

Although the use of trademarks is permissible in patent applications, the proprietary 
nature of the marks should be respected and every effort made to prevent their use in any manner 
which might adversely affect their validity as trademarks. 
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Information Disclosure Statement 

2. The Examiner apologizes that the Office has lost the Information Disclosure Statement 
filed on February 26, 2002. The Examiner respectfully requests that this Information Disclosure 
Statement be resubmitted. The fee and certification requirements of 37 CFR 1.97 are waived for 
those documents resubmitted in reply to this request. This waiver extends only to those 
documents that were submitted on February 26, 2002. Any supplemental replies subsequent to 
the first communication responding to this request and any information disclosures beyond the 
scope of this request are subject to the fee and certification requirements of 37 CFR 1.97 where 
appropriate. 

Claim Rejections - 35 USC § 101 

35 U.S.C. 101 reads as follows: 

Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new 
and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. 

3. Claims 10-15 are rejected under 35 U.S.C. § 101 because the claimed invention is 
directed to non- statutory subject matter. 



MPEP 2106 reads as follows: 

The claimed invention as a whole must accomplish a practical application. That is, it must produce a 
"useful, concrete and tangible result." State Street, 149 F.3d at 1373, 47 USPQ2d at 1601-02. The purpose 
of this requirement is to limit patent protection to inventions that possess a certain level of "real world" 
value, as opposed to subject matter that represents nothing more than an idea or concept, or is simply a 
starting point for future investigation or research (Brenner v. Manson, 383 U.S. 519, 528-36, 148 USPQ 
689, 693-96); In re Ziegler, 992, F.2d 1197, 1200-03, 26 USPQ2d 1600, 1603-06 (Fed. Cir. 1993)). 
Accordingly, a complete disclosure should contain some indication of the practical application for the 
claimed invention, i.e., why the applicant believes the claimed invention is useful. 
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4. Claim 10 recites a method that fails to produce a tangible result. A "mathematical 
simulation" is not limited to producing a tangible result. The Examiner respectfully suggests 
claiming the invention as producing some tangible output, such as displaying results of the 
simulation, or as achieving some physical transformation outside of the computer, such as 
controlling the facility network, as appropriate. 

Claim 13 is rejected for similar reasons. The step of "simulating as a function of time the 
transport phenomena" does not produce a tangible result. The recited steps are abstract and 
therefore not limited to the technological arts. 



MPEP 2106 reads as follows: 

Similarly, computer programs claimed as computer listings per se, i.e., the descriptions or expressions of 
the programs, are not physical "things." They are neither computer components nor statutory processes, as 
they are not "acts" being performed. Such claimed computer programs do not define any structural and 
functional interrelationships between the computer program and other claimed elements of a computer 
which permit the computer program's functionality to be realized. In contrast, a claimed computer- 
readable medium encoded with a computer program is a computer element which defines structural and 
functional interrelationships between the computer program and the rest of the computer which permit the 
computer program's functionality to be realized, and is thus statutory. Accordingly, it is important to 
distinguish claims that define descriptive material per se from claims that define statutory inventions. 

5. Claims 14 and 15 define a computer software architecture and are therefore nonfunctional 
descriptive material. Claim 14 recites "an object-oriented software architecture" which is 
abstract, intangible, and performs no method. Claim 15 recites additional limitations of the 
abstract, intangible "software architecture." 



MPEP 2106 reads as follows (emphasis added): 

Both types of "descriptive material" are nonstatutory when claimed as descriptive material per se. 
Warmerdam, 33 F.3d at 1360, 31 USPQ2d at 1759. When functional descriptive material is recorded on 
some computer-readable medium it becomes structurally and functionally interrelated to the medium and 
will be statutory in most cases since use of technology permits the function of the descriptive material to be 
realized. Compared re Lowry, 32 F.3d 1579, 1583-84, 32 USPQ2d 1031, 1035 (Fed. Or. 1994) (claim to 
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data structure stored on a computer readable medium that increases computer efficiency held statutory) and 
Warmer dam, 33 F.3d at 1360-61, 31 USPQ2d at 1759 (claim to computer having a specific data structure 
stored in memory held statutory product-by-process claim) with Warmerdam, 33 F.3d at 1361, 3 1 USPQ2d 
at 1760 (claim to a data structure per se held nonstatutory). When nonfunctional descriptive material is 
recorded on some computer-readable medium it is not statutory since no requisite functionality is present 
to satisfy the practical application requirement. Merely claiming nonfunctional descriptive material stored 
in a computer-readable medium does not make it statutory. Such a result would exalt form over substance. 
In re Sarkar, 588 F.2d 1330, 1333, 200 USPQ 132, 137 (CCPA 1978) ("[E]ach invention must be evaluated 
as claimed; yet semantogenic considerations preclude a determination based solely on words appearing in 
the claims. In the final analysis under 101, the claimed invention, as a whole, must be evaluated for what it 
is.") (quoted with approval mAbele, 684 F.2d at 907, 214 USPQ at 687). See also In re Johnson, 589 F.2d 
1070, 1077, 200 USPQ 199, 206 (CCPA 1978) ("form of the claim is often an exercise in drafting"). Thus, 
nonstatutory music is not a computer component and it does not become statutory by merely recording it on 
a compact disk. Protection for this type of work is provided under the copyright law. 

6. Claims 14 and 15 are directed to an abstract software architecture and are therefore 
nonstatutory. Amending these claims to incorporate the software architecture onto a computer- 
readable medium will not make the claimed inventions statutory because there is no functionality 
recited by these claims. A software architecture is not a software program; it is a representation 
of the abstract structure of a software program. 



7. Additionally, claim 15 makes reference to limitations such as a "WmSystem controller 
class", a "Case class", and a "ValueUse class" which specifically refer to computer software per 
se as depicted in Fig. 2. Computer software is not statutory subject matter that can be protected 
by US Patent. The Examiner respectfully suggests claiming Applicants' invention as a computer 
system comprising software with limitations that refer to the methods performed by the software 
rather than referring to the particular software by name. 

To expedite a complete examination of the instant application the claims rejected under 35 
U.S.C. § 101 (nonstatutory) above are further rejected as set forth below in anticipation of 
applicant amending these claims to place them within the four statutory categories of invention. 
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Claim Rejections - 35 USC § 112 
The following is a quotation of the first paragraph of 35 U.S.C. 1 12: 

The specification shall contain a written description of the invention, and of the manner and process of making 
and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it 
pertains, or with which it is most nearly connected, to make and use the same and shall set forth the best mode 
contemplated by the inventor of carrying out his invention. 

8. Claims 1-9 are rejected under 35 U.S.C. § 112, first paragraph, as failing to comply with 
the enablement requirement. The claim(s) contains subject matter which was not described in 
the specification in such a way as to enable one skilled in the art to which it pertains, or with 
which it is most nearly connected, to make and/or use the invention. 

MPEP 2164.01(a) lists several factors that can contribute to the determination whether 
experimentation is "undue". These factors include, but are not limited to: 

• The state of the prior art; 

• The nature of the invention; 

• The level of one of ordinary skill; 

• The existence of working examples; and 

• The quantity of experimentation needed to make or use the invention based on the 
content of the disclosure. 

The limitation of "the extensible class hierarchy permitting the addition of additional 
object types and additional member variables without any modifications to the class hierarchy 
itself prevents a person of ordinary skill in the art from making and using the invention. The 
state of the prior art is such that existing programming languages that support object-oriented 



Application/Control Number: 10/016,619 Page 7 

Art Unit: 2123 

programming by various implementations define a class hierarchy according to the class types. 
The class hierarchy is a representation of the existing object types. The addition of new object 
types to the hierarchy, through inheritance, derivation, or some other equivalent, necessarily 
changes that class hierarchy. Evidence of working examples of programming languages that 
exhibit this behavior would be appreciated. 

The nature of the invention is a means for simulating transport phenomena such as 
extracting oil from a subterranean hydrocarbon-bearing reservoir, not directly related to 
programming language design. In order to make and use the invention as claimed, a person of 
ordinary skill in the art would be required to invent an undisclosed programming language that 
facilitates this particular behavior. 

The act of designing computer programming languages is highly complex, undertaken 
almost exclusively by highly educated experts in that specific field, and often requires a 
prohibitive investment in time and money. Programming languages such as Ada have gone 
through numerous versions throughout the years, and are referred to as Ada95 (1995), Ada83 
(1983), and so on. 

As a result of these considerations, undue experimentation would be required to make 
and use the claimed invention wherein "the extensible class hierarchy" would permit "the 
addition of additional object types and additional member variables without any modifications to 
the class hierarchy itself. 

Claims rejected but not specifically mentioned stand rejected by virtue of their 
dependence. 
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The following is a quotation of the second paragraph of 35 U.S.C. § 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject 
matter which the applicant regards as his invention. 

9. Claim 7 is rejected under 35 U.S.C. § 112, second paragraph, as being indefinite for 
failing to particularly point out and distinctly claim the subject matter which applicant regards as 
the invention. 

Claim 7 presents several difficulties that render the scope of the claim indefinite. It is 
unclear whether the recitation of "additional data member types" is intended to refer to the "first 
set of generic classes representing a plurality of object types" from claim 1, the "second set of 
generic classes representing member variables for the object types" from claim 1, or represents 
something else entirely. It is unclear whether "additional facility data members" refers to 
"additional data members" as recited earlier in the claim. The claim recites "the user" which 
lacks sufficient antecedent basis. It is unclear whether the later recitation of "a user" presents a 
second user or if it refers to "the user". The Examiner notes that the language of claim 6 appears 
to be more related to that of claim 6 than of claim 1 . 

Claims rejected but not specifically mentioned stand rejected by virtue of their 

dependence. 

i 

Claim Rejections - 35 USC §102 
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis 
for the rejections under this section made in this Office action: 
A person shall be entitled to a patent unless - 



1: V . . 
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(b) the invention was patented or described in a printed publication in this or a foreign country or in public 
use or on sale in this country, more than one year prior to the date of application for patent in the United 
States. 

10. Claims 1, 8-9, and 14 are rejected under 35 U.S.C. § 102(b) as being anticipated by "The 
C++ Programming Language, Third Edition" by Bjarne Stroustrup (1997). 

Regarding claim 1, Stroustrup discloses a computer programming language that 
implicitly discloses the use of a modern computer system comprising memory means, storage 
means, and software created using the C++ programming language. 

Stroustrup discloses a class hierarchy (page 735, either figure) comprising a first set of 
generic classes representing a plurality of object types (example: Car or Truck) and a second set 
of generic classes representing member variables for the object types [ "The 'plain 1 cars and 
trucks are initialized with Vehicle::eptr zero; the others are initialized with Vehicle::eptr 
nonzero. " (page 736) Also, example: Police_car, class definition of Police_car] and wherein 
the hierarchy is designed to be expanded as necessary [section 24.3. 2 .1 Dependencies within a 
Class Hierarchy; "If however, the intent is to provide a framework into which a later 
programmer can add code, then virtual functions are often an elegant mechanism for achieving 
this..." (page 738)]. 

The use of the object-oriented extensible class hierarchy for the storage of transport 
phenomena simulation data is regarded as intended use. Stroustrup discloses the use of the 
extensible class hierarchy for the storage of vehicle data (page 738). MPEP 2111.02 reads as 
follows: 

If a prior art structure is capable of performing the intended use as recited in the preamble, then it meets, the 
claim. See, e.g., In re Schreiber, 128 F.3d 1473, 1477, 44 USPQ2d 1429, 1431 (Fed. Cir. 1997) 
(anticipation rejection affirmed based on Board's factual finding that the reference dispenser (a spout 
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disclosed as useful for purposes such as dispensing oil from an oil can) would be capable of dispensing 
popcorn in the manner set forth in appellant's claim 1 (a dispensing top for dispensing popcorn in a 
specified manner)) and cases cited therein. See also MPEP § 21 12 - § 21 12.02. 

Although the intended use is not recited by the preamble, the body of the claim is directed 

toward the structure of the extensible class hierarchy and thus defines the intended use for that 

hierarchy. The class hierarchy of Stroustrup is clearly capable of performing the intended use as 

stated, for example, by replacing the vehicle data with transport phenomena simulation data, and 

therefore meets the claim. 

Regarding claim 8, Stroustrup discloses software written in C++ (pages 732-733). 

Regarding claim 9, Stroustrup discloses a hierarchy of logically related data (page 735, 
either figure, corresponding implementation illustrated on page 736). 

The Authoritative Dictionary of IEEE Standards Terms, Seventh Edition, provides the 
following definition relied upon for this rejection: 

database A collection of logically related data stored together in one or more computerized files. 

Regarding claim 14, Stroustrup discloses an object-oriented software architecture (pages 
732-733). 

Stroustrup discloses a hierarchy of classes (page 735, either figure). 
Stroustrup discloses derived classes (page 737). 

Stroustrup discloses that classes contain member variables of various primitive types 
(pages 224-227, i.e. class Date (page 227) contains integers d 9 m y and;/). 
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Stroustrup discloses that classes have a many-to-one relationship with the base class. 
This is known as the concept of instance classes, which can be created as necessary to implement 
the program. This creates many instances that are all related to the same base class. 



Claim Rejections - 35 USC § 103 
The following is a quotation of 35 U.S.C. § 103(a) which forms the basis for all obviousness 
rejections set forth in this Office action: 

A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art 
are such that the subject matter as a whole would have been obvious at the time the invention was made to 
a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be 
negatived by the manner in which the invention was made. 

11. Claims 2-4 are rejected under 35 U.S.C. § 103(a) as being unpatentable over Stroustrup 

as applied to claim 1 above, and further in view of US Patent No. 6,038,389 to Rahon et al. 

(Rahon). 

Stroustrup does not expressly teach the details of Applicants' particular intended use, 
although the class hierarchy of Stroustrup is capable of performing the intended use of claims 2 
through 4. 

Rahon teaches a method of modeling a physical process in a material environment 
(abstract) with an exemplary use of a hydrocarbon reservoir. Rahon models the transport 
phenomena [ 'Tumping has been simulated during 86,400 seconds (1 day), with a flow rate of 30 
m 3 /day. " (column 6, lines 48-50); 'TIG. 1 [a graph of kPa at t(s) (pressure dependent on time)] 
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compares the values obtained by means of the method according to the invention to the values 
obtained by means of a conventional time division type method.., " (column 6, lines 5 1-64)]. 

It would have been obvious to a person of ordinary skill in the art at the time of 
Applicants' invention to combine Rahon's method of modeling a physical process, such as the 
transport phenomena in a hydrocarbon reservoir through a well to the earth's surface, with the 
class hierarchy capable of storing data as taught by Stroustrup. The combination could be 
achieved by representing the various components of Rahon's model [grid pattern, well, pumping, 
etc. (column 6, lines 42-50)] as the objects (storing the appropriate simulation data) and methods 
of a class hierarchy as taught by Stroustrup. Motivation to do so is explicitly taught by 
Stroustrup, such as an enhanced ability to understand how the model works [ "The point about 
modeling reality is not to slavishly follow what we see but rather to use it as a starting point for 
design, a source of inspiration, and an anchor to hold on to when the intangible nature of 
software threatens to overcome our ability to understand our programs. " (page 734)]. 

Regarding claims 3 and 4, Rahon teaches a transport pathway including a well and, by 
modeling pumping, implicitly teaches modeling a pump (column 6, lines 40-50). The 
combination and motivation to combine are the same as those for claim 2. A pump and a well 
constitute a facility network through which hydrocarbon fluids are transported between the 
subsurface reservoir and the delivery locations. 

Regarding claim 5, the specification defines a "Data Definitions File": 

In the current system, clear-text file, for example, an ASCII file, which can be referred to as a "Data 
Definitions File" contains text entries that define each facility type and all of the attribute values for each 
facility type, (page 16, lines 28-31) 
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Stroustrup teaches a clear-text file that contains text entries that define each object type 
and all of the attribute values for the objects (excerpts shown on page 736, 737, et cetera), which 
are generally referred to in the art of software engineering as "class definitions" in "source code" 
(see pages 33-34). 

12. Claim 6 is rejected under 35 U.S.C. § 103(a) as being unpatentable over Stroustrup as 
applied to claim 1 above, and further in view of US Patent No. 6,842,725 to Sarda. 

Regarding claim 6, Stroustrup does not expressly teach the graphical user interface. 

Sarda teaches a method for modeling fluid flows in a hydrocarbon reservoir (column 2, 
lines 5-18). Sarda teaches a user interface wherein a user defines the specific well network for 
the reservoir [detailed description, section 5, "Simulation input data", "The data relative to the 
well are: its geometry, in the form of a series of connected segments^, and] the imposed flow 
rates, in the form of a curve giving the imposed flow rate as a function of time. " (column 8, lines 
28; 53-59)]. Sarda teaches a graphical interface concerning the well \"A well is a series of 
connected segments that intersect the network fractures. The geometric representation of a well 
is therefore a 3D broken line. " (column 5, lines 60-63)]. Sarda both suggests and implies the use 
of a graphical user interface for defining the specific network of wells and facility objects to 
simulate transport phenomena into and out of a specific hydrocarbon-bearing reservoir. 

It would have been obvious to a person of ordinary skill in the art at the time of 
Applicants' invention to combine the teachings of Sarda regarding graphical modeling of fluid 
flows, specifically including a model of a well as a series of connected segments, with the object 
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oriented software design taught by Stroustrup. The combination could be achieved by 
representing the various components of Sarda's model (segments of the well, nodes of the mesh, 
et cetera) as objects in a class hierarchy. Motivation to do so is explicitly taught by Stroustrup, 
such as an enhanced ability to understand how the model works ["The point about modeling 
reality is not to slavishly follow what we see but rather to use it as a starting point for design, a 
source of inspiration, and an anchor to hold on to when the intangible nature of software 
threatens to overcome our ability to understand our programs. " (page 734)]. 

13. Claim 7 is rejected under 35 U.S.C. § 103(a) as being unpatentable over Stroustrup as 
applied to claim 1 above, and further in view of "Design Patterns: Elements of Reusable Object- 
Oriented Software" by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides 
(Vlissides, 1995). 

Regarding claim 7, Stroustrup does not expressly teach a graphical user interface through 
which a user can define additional data members. 

Vlissides teaches a design pattern for object-oriented software called the "Factory 
Method" (page 107) wherein an exemplary use is shown (page 107) depicting, in flowchart form, 
a user interface wherein a user of a computer system can create additional data objects 
(Documents) by using a graphical user interface. Vlissides shows an exemplary "user 
customized" data member [MyApplication] that contains its own user-customized 
CreateDocumentQ member function. 
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It would have been obvious to a person of ordinary skill in the art at the time of 
Applicants' invention to combine the Factory Method design pattern taught by Vlissides, 
especially in light of Vlissides' examples, with the object-oriented programming language taught 
by Stroustrup to achieve a graphical user interface through which a user can define additional 
data members. The combination could be achieved by using a user-customized CreateFacilityQ 
function, wherein the nature of the problem to be solved would motivate a person of ordinary 
skill in the art to customize that function to the particular intended use at hand. Motivation to 
combine is expressly taught by Vlissides [ "Use the Factory Method pattern when: a class can 't 
anticipate the class of objects it must create; a class wants its subclasses to specify the objects it 
creates; classes delegate responsibility to one of several helper subclasses, and you want to 
localize the knowledge of which helper subclass is the delegate. " (page 108) All these reasons 
relate directly to customization of the classes at a later point in time.]. 



14. Claims 10-12 are rejected under 35 U.S.C. § 103(a) as being unpatentable over Sarda. 

Regarding claim 10, Sarda teaches a method for modeling fluid flows in a hydrocarbon 
reservoir (column 2, lines 5-18) including a facility network ["A well is a series of connected 
segments that intersect the network fractures. The geometric representation of a well is 
therefore a 3D broken line. " (column 5, lines 60-63)]. Sarda teaches a user interface wherein 
user specifies values of the member variables for each facility [detailed description, section 5, 
"Simulation input data", "The data relative to the well are: its geometry, in the form of a series 
of connected segments^ and] the imposed flow rates, in the form of a curve giving the imposed 
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flow rate as a function of time. " (column 8, lines 28; 53-59)]. Sarda teaches using the specified 
values in a mathematical simulation of transport phenomena within the facility network as a 
function of time [ "In order to simulate a well test, whatever the medium, this equation has to be 
solved in space and in time. Discretization of the reservoir (mesh pattern) is therefore 
performed and solution of the problem consists in finding the pressures of the meshes with time, 
itself discretized in a certain number of time intervals. " (column 2, lines 24-47)]. 

It would have been obvious to a person of ordinary skill in the art to implement the model 
taught by Sarda in object-oriented software because the advantages of object-oriented software 
are well known to persons of ordinary skill. See, for example, Stroustrup. 

Regarding claim 11, Sarda teaches that the facility network is part of a larger simulation 
model, with said facility network being capable of exchanging fluids with at least one other part 
of the simulation model [fluid from the reservoir is transferred via the series of connected 
segments that form the facility network of the well (column 2, lines 55-67)]. 

Regarding claim 12, Sarda teaches that the simulation model comprises a facility network 
[ "A well is a series of connected segments that intersect the network fractures. The geometric 
representation of a well is therefore a 3D broken line.*' (column 5, lines 60-63)] and a 
hydrocarbon-bearing formation ["Discretization of the reservoir (mesh pattern) is therefore 
performed and solution of the problem consists in finding the pressures of the meshes with time, 
itself discretized in a certain number of time intervals. " (column 2, lines 43-47)]. 
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15. Claim 13 is rejected under 35 U.S.C. § 103(a) as being unpatentable over US Patent No. 
6,434,435 to Tubel et al. (Tubel) in view of Sarda. 

Regarding claim 13, Tubel teaches an object-oriented software for control of a 
hydrocarbon production system (column 1, lines 14-50). Although Tubel is primarily concerned 
with the control of such a system, the disclosed invention can also perform in a simulation mode 
[ "...in the simulation mode, simulated and/or calculated sensor and actuator data may be used 
in place of data from real-world sensors and actuators. Simulation of real or abstract systems 
occurs by having an ISO 10 evaluate or interrogate a model of a real or abstract thing or system 
or evaluate and/or interact with rules associated with the real or abstract thing. " (column 12, 
lines 6-18)]. 

Tubel teaches a controlling (and therefore simulating) a hydrocarbon-bearing reservoir 
penetrated by a plurality of wells and surface facilities connected to the wells ["...the present 
invention relates to management of hydrocarbon production from a single production well (e.g., 
only well 642) or from a group of wells, shown in FIG 28 as well 640. well 64 L and well 642 ." 
(column 23, lines 8-15); "Referring still to FIG. 28, as is well known in the art a given well may 
be divided into a plurality of separate zones, such as zone 640a, zone 640b, and zone 640c. Such 
zones may be positioned in a single vertical well such as well 640 assocaited with surface 
platform 645. or such zones may result when multiple wells are linked or otherwise joined 
together (not shown in FIG 28). " (column 26, lines 52-58, emphasis added)]. 

Tubel teaches using objects and variables in a class hierarchy to model the wells and 
surface facilities ["Referring now to FIG 30, a diagrammatic representation of ISOs 10 in flow 
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and hierarchical relationships, ISOs 10 can model and represent any device or group of devices 
including sensors 200, controllable devices 300, fluid processing devices 400, injection devices 
500, or any combination thereof ISOs 10 can also model and represent more abstract processes 
such as a single zone like 640a, a group of zones such as 640 a and 640b, an entire well such as 
well 640, or an entire field such as wells 640, 641, and 642. " (column 25, lines 23-3 1)]. 

Tubel does not teach discretizing the reservoir into a plurality of volumetric cells, each 
modeled as nodes, and simulating the exchange of fluid between those nodes. 

Sarda teaches discretizing the reservoir into a mesh pattern (consisting of interconnected 
nodes) used to model the reservoir by finding the pressure of the oil contained therein as a 
function of time (column 2, lines 24-47).. In this method, the model simulates the flow of fluid 
through a porous medium, accounting for the real geometry of the fracture network (found in the 
reservoir) and thus simulates the interactions between the pressure and flow rate variations in a 
well running across the medium (column 2, lines 55-67). Sarda teaches specifying initial 
conditions for each node and connection (column 4, lines 33-64). 

It would have been obvious to a person of ordinary skill in the art at the time of 
Applicants' invention to combine Sarda' s method for modeling the flow of fluid in a reservoir 
with Tubel 's object-oriented method of modeling a facility network. The combination could be 
achieved by operating Tubel' s method in simulation mode, wherein the data calculating the 
transport phenomena of the underground reservoir is supplied by Sarda' s method and delivered 
to the sensors and actuators modeled by Tubel. Motivation to combine would be found in the 
knowledge of a person of ordinary skill in the art as well as the nature of the problem to be 
solved; Tubel' s simulation mode requires calculated sensor and actuator data while the results of 
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Sarda's model provide an efficient and accurate representation of the transport phenomena that 
would be detected by Tubel's sensors. 

16. Claim 15 is rejected under 35 U.S.C. 103(a) as being unpatentable over Stroustrup as 
applied to claim 14 above. 

Claim 15 recites various named components of object-oriented software that would have 
been obvious to a person of ordinary skill in the art when confronted with a particular problem. 
The claim does not positively recite the functionality performed by these classes. Stroustrup 
(page 735) teaches such components, such as the "Car" class that has a relationship to the base 
class "Vehicle". The "Emergency" class can be used by objects of the "Car" class,, specifically 
"Police_car" and "Ambulance". 

Conclusion 

Art considered pertinent by the examiner but not applied has been cited on form PTO- 

892. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Jason Proctor whose telephone number is (571) 272-3713. The 
examiner can normally be reached on 8:30 am-4:30 pm M-F. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Leo Picard can be reached at (571) 272-3749. The fax phone number for the 
organization where this application or proceeding is assigned is (571) 273-3713. 
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Any inquiry of a general nature or relating to the status of this application should be 
directed to the TC 2100 Group receptionist: 571-272-2100. Information regarding the status of 
an application may be obtained from the Patent Application Information Retrieval (PAIR) 
system. Status information for published applications may be obtained from either Private PAIR 
or Public PAIR. Status information for unpublished applications is available through Private 
PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. 
Should you have questions on access to the Private PAIR system, contact the Electronic Business 
Center (EBC) at 866-217-9197 (toll-free). 



Jason Proctor 
Examiner 
Art Unit 2123 





